home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20030409-20031118 / 000038_fdc@columbia.edu_Thu May 1 13:27:42 EDT 2003.msg < prev    next >
Text File  |  2003-11-18  |  4KB  |  98 lines
  1. Article: 14253 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail
  3. From: fdc@columbia.edu (Frank da Cruz)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: Changed behavior of receive/transmit move-to
  6. Date: 1 May 2003 13:10:10 -0400
  7. Organization: Columbia University
  8. Lines: 81
  9. Message-ID: <b8rkdi$mo0$1@watsol.cc.columbia.edu>
  10. References: <b8rfll$kfv$1@cpimail.cpicorp.com>
  11. NNTP-Posting-Host: watsol.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1051809012 5710 128.59.39.139 (1 May 2003 17:10:12 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 1 May 2003 17:10:12 GMT
  15. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:14253
  16.  
  17. In article <b8rfll$kfv$1@cpimail.cpicorp.com>,
  18. Derek Chen-Becker  <dbecker@cpicorp.com> wrote:
  19. :      The behavior of the set receive move-to command seems to have 
  20. : changed between c-kermit 8.206 and 8.209. It used to resolve the full 
  21. : path of the move-to target upon each transfer, and now it appears to 
  22. : resolve it on login through IKSD. We have a directory structure like this:
  23. : 
  24. : ~/
  25. : ~/a
  26. : ~/a/incoming
  27. : ~/a/complete-rx
  28. : ~/a/outgoing
  29. : ~/a/complete-tx
  30. : ~/b
  31. : ~/b/incoming
  32. : ~/b/complete-rx
  33. : ~/b/outgoing
  34. : ~/b/complete-tx
  35. : 
  36. : The .kermrc for the account had lines like:
  37. : 
  38. : set receive move-to complete-rx
  39. : set send move-to complete-tx
  40. : 
  41. : Under 8.206 we could change to directory "a" or directory "b" and issue 
  42. : a send command like "send test.txt incoming/test.txt". The incomplete 
  43. : file during transfer would sit in the appropriate incoming directory and 
  44. : then would be moved to the approprate complete-rx directory on 
  45. : completion. Under 8.209 the completed files sit in the incoming 
  46. : directory unless we create a "complete-rx" directory in the home:
  47. : 
  48. : ~/complete-rx
  49. : 
  50. : and then they move there no matter which incoming directory they 
  51. : arrived in.
  52. :
  53. I would venture to say that the behavior you were relying on was not
  54. intentional.  Although my notes don't show it, I suspect that somebody else
  55. -- maybe even me -- was surprised when a relative directory name was not
  56. resolved in the context in which the command was given, especially since
  57. after changing contexts it might not be be valid.
  58.  
  59. : If this was for one or two sites we could work around it by creating 
  60. : different accounts for each one, but this is for 1200+ sites and one 
  61. : account makes it managable.
  62. :
  63. Well, when you put it that way I can see how deferred evaluation could be 
  64. useful too, in a use-at-your-own-risk sort of way.  But this turns out to
  65. be a rather tricky question, since immediate and deferred evaluation can
  66. be applied independently to the context (current directory for relative
  67. filespecs) and to any variables in the MOVE-TO or RENAME-TO string, e.g.:
  68.  
  69.   SET RECEIVE RENAME-TO \v(filename)_\v(ndate)_\v(ntime)_\v(userid)_\v(pid)
  70.  
  71. Deferring evaluation of the MOVE/RENAME-TO string until it is used means
  72. that an error might not be detected until hours into the operation, after
  73. everybody has gone home.
  74.  
  75. : If I could remotely set the send/receive move-to destinations, that 
  76. : might work, too.
  77. :
  78. That would be a change too.  But clearly changes are necessary, especially
  79. since in researching this I discovered that the SET RECEIVE RENAME-TO
  80. example (which is taken from the C-Kermit 7.0 update notes) is broken too.
  81.  
  82. My first reaction would be accept the MOVE-TO/RENAME-TO argument as-is
  83. at parse time, with no checking, and then evaluate it upon use.  This way,
  84. if you give an absolute pathname, it is constant; if you give a
  85. relative one, its resoluation varies with the context.  To extend same
  86. flexiblity to variables in the string, such as \v(time), we'd have to
  87. evaluate them at *parse* time.  If the user wanted to defer evaluation
  88. until use, s/he'd have to double the backslash.  A tad hard to explain,
  89. but it leaves the user with every combination of choices.  If I get a
  90. chance to work on the code again, I'll try this and see how it feels.
  91.  
  92. In the meantime, I'd recommend you fall back to whatever version of
  93. C-Kermit you were using before.
  94.  
  95. Thanks for the report.
  96.  
  97. - Frank
  98.